(Transcribed by TurboScribe. Go Unlimited to remove this message.)

Mijn vraag was meer wat je bedoelt met ticket, bedoel jij dat een ticket een kanban item is op het boord, zeg maar, zo noem ik een ticket. Maar stel je voor je maakt een plan, er moet iets gefixt worden, dan kan je natuurlijk meerdere tickets maken voor een plan. Dus wat jij een plan noemt is natuurlijk een subset van alle tickets op een boord.

En meerdere tickets op een boord kunnen van hetzelfde plan komen. Dus daarom zou ik zeggen, één agent per plan, die orchestrate het plan. Want je wil natuurlijk dat het hele plan uitgevoerd wordt.

Maar plan is natuurlijk in principe een sequence diagram, toch? Want nu zie ik in jouw applicatie dat je vooral to-do lijsten gebruikt, maar er zit niet echt een dependency op, ofwel? Of je hebt phases, dat is inderdaad, jij hebt phases, oké. Dus in theorie is het zo dat de plan orchestrator, dat moet een agent zijn, die orchestrate gewoon dat eerst phase één taken wordt uitgevoerd, en als die allemaal af zijn, dan phase twee taken, omdat het een dependency heeft. Maar je wilt dus wel een agent orchestraten, een agent per plan, en niet een environment agent.

Althans, je kan wel een environment agent hebben als gewoon puur van, hé, hoe gaat het met dit of dat? Gewoon puur, die is gewoon jouw co-assistent. Maar je moet wel een worker agent per plan hebben. En die delegate dus, die spant dus losse agents, dus niet sub-agents, maar losse agents per task die die wil uitvoeren.

Stel je voor, hij zit nu in phase 1, en hij heeft drie tasks in phase 1, en ik bedoel, tasks zijn natuurlijk tickets dan, dan spant hij drie agents voor die drie sub-tickets. En die tickets hebben allemaal dus een eigen, ook een eigen orchestrate agent, en die kunnen op zichzelf, om hun taken te voldoen, kunnen communiceren met, hé, volgens mij moet ik vragen aan, of ik moet bijvoorbeeld een instantie van dit type agent opspinnen. En dan heb je het over de agents in de organic organization, dus bijvoorbeeld een developer.

En aangezien een developer dus niet een one, ik zag al dat je dat zo noemde, maar one agent per ticket, of nee, one agent per ticket is, een developer kan je oneindig spannen. Dus bijvoorbeeld deze agent kan gewoon een developer spannen, maar ook een ander ticket kan een developer spannen, en nog een ander ticket kan een developer spannen, of zelfs twee developers spannen. Maar stel je voor, je hebt one agent per plan, want het plan is natuurlijk een worktree als het goed is, maar stel je voor, je hebt one agent per plan, bijvoorbeeld de feature planner of zo, dan komt hier een queue als het goed is.

Misschien wordt het weer een lange memo, maar dit is wel even goed om uit te leggen denk ik. En je hebt dus ook een type agent, dus stel je voor de deployment agent, is natuurlijk een global agent. Die staat buiten de plan, want die is verantwoordelijk voor deployments, en daar is er überhaupt maar één van in heel journal, want je kan niet twee deployment agents hebben, zeg maar.

(Transcribed by TurboScribe. Go Unlimited to remove this message.)